Subject: Re: Wayne's comments on current DLSW

From: "almost, but not quite, entirely unlike tea 12-Jul-1993 1037 -0400" <"simgr::graham"@smaug.enet.dec.com>
Date: Mon, 12 Jul 93 10:36:10 EDT

; 	(1) the current DLSw plays too active a role in the station-to-station
; 	    exchange:
; 	    (a) by not passing DLC events at Connect and Disconnect time
; 		end-to-end between the stations, you get:
; 		 (i) RNR at Connect time,

What do you propose instead? If you don't respond to the SNRM until you get
a reply from the remote end, then you are going to get some failures to
connect due to timeouts (especially if CANUREACH is being used to locate the
remote end...). You also have to decide what to do with retransmitted SNRMs
(ignore them I guess). Since it is also possible to get NCP to generate alerts
when REPLYTO expires, you can also still get alerts generated in this case
(although I grant you it is less likely - anyone who turns on alert generation
for REPLYTO expiry is asking for trouble!)

; 		(ii) a rather disorderly take-down sequence that is very
; 		    tightly dependent upon local LLC2 events.

I don't understand this - am I missing something? The sequence

Primary		Rtr1			Rtr2		Secondary
   |  DISC        |                       |                 |
   |------------->|       HALT_DL         |                 |
   |  UA          |---------------------->|     DISC        |
   |<-------------|                       |---------------->|
   |              |                       |     UA          |
   |              |       DL_HALTED       |<----------------|
   |              |<----------------------|                 |

Seems fine to me!

; 	    (b) making NT 2.1 support very complex:
; 		 (i) with the current design, XID3 must be performed between
; 		     the switch and the end stations, not between end stations

Again, I'm not sure I agree - there already exists the capbility to pass XIDs
end to end (maybe not being used yet, but there in the protocol). As I see it
there are two stages to supporting 2.1:

1. The first stage it to provide a completely transparent pipe for XID3
   negotiation - XID-3 are passed through unchanged, and the routers at either
   end merely look at the DLC-specific portion to see what DLC parameters
   have been negotiated - you don't need to follow the negotiation, since the
   DLC portion of the XID-3 isn't supposed to change once negotiation starts -
   for simplicity, just use the values form the alst XID to pass through.

   Now, I realise this doesn't allow for SDLC to LLC conversion since XID
   format changes...

2. Stage 2 adds in the ability to modify the XID as it passes through. Even
   this is not terribly difficult though - XIDs sent over the IP network would
   have to be in a common format (probably LAN-type), and the routers at either
   end would send XIDs to end systems that allow the maximum possible support, 
   and allow the end systems to negotiate downwards. However, this does involve 
   potential resegmenting of frames from large to small max BTU size links. 
   Since the DLC-specific portion of the XID doesn't change during negotiation, 
   there is again no need to implement the XID FSMs in the routers - you just 
   have to peek at it on the way through, and convert between LAN and SDLC 
   specific formats where necessary.

; 	(2) the current DLSw is too loosely coupled with its DLC.
; ...
;        The loose coupling mentioned in (2) makes the end station-to-end station
;        operations impossible.

Could you explain what you mean here in more detail please.

Simon

---

From: [email-masked]
Date: Mon, 12 Jul 93 08:13:25 PDT

Simon -

    I'll give some brief answers below but I'd like to defer the
    complete reply until later today when I post the full sequences to
    the mailgroup.  (We have the flows complete but I want some of the
    other cisco engineers to review what I've done for completeness.)

>for REPLYTO expiry is asking for trouble!)

    We throttle the rate at which SNRMs are processed.  If a SNRM is awaiting
    a reply from the remote side, we only permit a SNRM to go through every
    'n' seconds, where 'n' is currently set at 5 seconds but could be
    made configurable (yuk).  Thus far, a value of 5 seconds appears to be
    100% effective ... no complaints from the field.

>   |  UA          |---------------------->|     DISC        |

    What I will show later today will be something that looks like (for
    NRM DLC):

Primary		Rtr1			Rtr2		Secondary
   |  DISC        |                       |                 |
   |------------->|       HALT_DL         |                 |
   |              |---------------------->|     DISC        |
   |              |                       |---------------->|
   |              |                       |     UA          |
   |              |       DL_HALTED       |<----------------|
   |           UA |<----------------------|                 |
   |<-------------|                       |                 |
   |              |                       |                 |

			and the more revealing one:

Primary		Rtr1			Rtr2		Secondary
   |              |                       |              RD |
   |              |                       |<----------------|
   |              |       REQ_HALT_DL     |                 | 
   |           RD |<----------------------|                 |
   |<-------------|                       |                 |
   |  DISC        |                       |                 |
   |------------->|       HALT_DL         |                 |
   |              |---------------------->|     DISC        |
   |              |                       |---------------->|
   |              |                       |     UA          |
   |              |       DL_HALTED       |<----------------|
   |           UA |<----------------------|                 |
   |<-------------|                       |                 |
   |              |                       |                 |

    Admittedly, with the primary-initiated disconnect, it probably doesn't 
    matter if the UA is presented back to the primary link station before
    the secondary is taken down.  But in the secondary-initiated case,
    the primary side should be requested to take down the secondary.

    Of course, there are many ways to skin a cat ... this is the one we
    use for STUN.

>   for simplicity, just use the values form the alst XID to pass through.

    This is exactly what I'm proposing.  Maybe it is just a matter of 
    further explaining what happens with XID3 in the Connected state of DLSw.
    The RFC is pretty vague on this.  I recall some past email discussion
    on this so I will go back and refresh my memory.

>   specific formats where necessary.

    I believe we are in agreement here.  With XID3-capable SDLC devices such
    as the 3174, the above operations should work fine.  SDLC devices
    which are only XID0-capable will have to be handled more carefully and
    probably with router configuration information.

>Could you explain what you mean here in more detail please.

    If you look at the flow diagram I've shown above for STUN, I think
    you'll see what I mean by tighter coupling.  But I'll reiterate,
    this was our approach at cisco and isn't mandatory.  However, it does
    enable the routers to keep the end stations in a known, manageable
    state during start-up and take-down.

>Simon

Regards,
-----------
Wayne Clark
cisco Systems, Inc.
[email-masked]
415/688-4627

P.S. Simon, you have one strange email header :-).  I hope you get this reply.